What the issue is. .changeset/cjs-support-v2-packages.md marks all nine packages (server, client, core, server-legacy, codemod, express, hono, fastify, node) as patch. The PR itself is titled feat(packaging) and adds new backwards-compatible functionality: every package gains a require condition on each export leaf, new .cjs/.d.cts build artifacts, and a new main field for bare-require fallback. Under semver conventions, a new backwards-compatible feature is a minor bump, not a patch.

Why this is a surface addition, not a fix. The repo's own topology pin test (packages/core-internal/test/packageTopologyPins.test.ts) describes a CJS build as "a new public surface" — i.e. the project already treats dual-format output as an addition to the public API contract, not an internal detail. Repo precedent also points to minor for feature changesets even during the prerelease cycle: the toWebRequest export (#2390), SdkHttpError, and the auth-iss changesets were all recorded as minor, and packages/server/CHANGELOG.md already has "Minor Changes" sections from the 2.0.0-alpha/beta cycle (e.g. #2286, #1689). patch in this repo is used for docs and fixes.

Concrete walk-through of the effect. The workspace is in changesets pre mode (.changeset/pre.json, tag beta), and all nine packages are at 2.0.0-beta.1. When the release PR is generated: (1) changesets reads this file and sees patch for each package; (2) because semver-inc of a prerelease version yields the next prerelease regardless of bump type, the published version is 2.0.0-beta.2 whether the entry says patch or minor — so no version-number harm; (3) however, the changelog generator groups entries by bump type, so the "Ship CommonJS builds alongside ESM…" entry lands under a "Patch Changes" heading in each package's CHANGELOG.md. Consumers scanning the changelog for new capabilities would not expect a new require() entry point to be listed as a patch, and the release notes would misrepresent the nature of the change after the prerelease exits.

Why nothing else catches it. changeset-bot only verifies that a changeset exists and reports the declared bump types (its comment on this PR faithfully lists all nine as "Patch"); nothing validates that the bump type matches the semantic nature of the change.

How to fix. Change each frontmatter entry in .changeset/cjs-support-v2-packages.md from patch to minor (nine one-word edits). No other change is needed; the changeset body text is accurate.

Impact assessment. This is purely a changelog-categorization/convention issue — no build, runtime, or version-resolution behavior is affected, and in pre mode the published version is identical either way. It should not block merge; it's just worth a quick edit so the release notes categorize the CJS support as the feature it is.

What the issue is. The rewritten "CommonJS test runners (Jest)" section (docs/migration/upgrade-to-v2.md:258-259) now reads: "If you carried a v1-era mapping that pinned these packages to their dist/*.mjs files, remove it." The mapping being described is unambiguously the moduleNameMapper recipe that this same guide prescribed for the v2 alpha/beta ESM-only packaging — the section this PR deletes explicitly called it "the interim recipe — interim because the packaging shape is still under discussion and a later alpha may make it unnecessary." Users who added it did so while already on v2 prereleases, not on v1.\n\nWhy "v1-era" cannot be right. A v1-era mapping to dist/*.mjs could not have existed:\n\n1. The bare specifiers the recipe maps — @modelcontextprotocol/client, @modelcontextprotocol/server, and the /_shims self-reference — only exist in v2. v1 was the single @modelcontextprotocol/sdk package.\n2. v1 shipped dist/cjs/ and dist/esm/ .js flavor pairs (as this same guide notes a few lines above, ~233-235) and resolved fine under Jest's default CommonJS resolution, so no moduleNameMapper was ever needed for v1, and no dist/index.mjs / dist/shimsNode.mjs paths existed to pin.\n\nStep-by-step reader scenario showing the impact. (1) A user upgraded to 2.0.0-beta.1 a few weeks ago and, following this guide's then-current Jest section, added moduleNameMapper entries pointing @modelcontextprotocol/client at dist/index.mjs and /_shims at dist/shimsNode.mjs. (2) They upgrade to the release that ships this PR and re-read the Jest section. (3) The guide tells them to remove a "v1-era mapping" — they never migrated a Jest config from v1, or they grep for something v1-flavored, don't recognize the mapping they added during the beta as the thing being referred to, and leave it in place. (4) The stale pin keeps routing resolution straight to the .mjs dist files through the transform-based path, silently bypassing the new require condition this PR ships — exactly the workaround the section says is no longer needed.\n\nWhy nothing else catches it. This is prose in a migration guide; no test or lint validates the historical attribution, and the sentence was introduced by this PR's own rewrite (commit c3241d8), so it is in scope for this review.\n\nHow to fix. One-line reword, e.g.: "If you carried the earlier v2-beta moduleNameMapper workaround that pinned these packages to their dist/*.mjs files, remove it" (or "the interim mapping this guide previously prescribed"). Everything else in the rewritten section is accurate.\n\nSeverity. Documentation prose accuracy only — nothing breaks at merge time and the fix is a few words, so this is a nit, not a blocker.